Feature reset integration test should tolerate failed resets #72326
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
williamrandolph
added
:Core/Infra/Plugins
|
Pinging @elastic/es-core-infra (Team:Core/Infra) |
williamrandolph
commented
Apr 27, 2021
| .map(ResetFeaturesResponse.ResetFeatureStateStatus::getStatus) | ||
| .collect(Collectors.toSet()); | ||
|
|
||
| assertThat(statuses, contains("SUCCESS")); |
There was a problem hiding this comment.
This was redundant with the check on line 55/58.
williamrandolph
added a commit
to williamrandolph/elasticsearch
that referenced
this pull request
Apr 27, 2021
…#72326) * Remove redundant section of test * Mention in javadoc that we check task index specifically
williamrandolph
added a commit
that referenced
this pull request
Apr 27, 2021
* Make feature reset API response more informative (#71240) Previously, the ResetFeatureStateStatus object captured its status in a String, which meant that if we wanted to know if something succeeded or failed, we'd have to parse information out of the string. This isn't a good way of doing things. I've introduced a SUCCESS/FAILURE enum for status constants, and added a check for failures in the transport action. We return a 207 if some but not all reset actions fail, and for every failure, we also return information about the exception or error that caused it. * Fix 7.x backport compilation issues * Feature reset integration test should tolerate failed resets (#72326) Co-authored-by: Jay Modi <[email protected]>
williamrandolph
added a commit
to williamrandolph/elasticsearch
that referenced
this pull request
Apr 27, 2021
…stic#72332) * Make feature reset API response more informative (elastic#71240) Previously, the ResetFeatureStateStatus object captured its status in a String, which meant that if we wanted to know if something succeeded or failed, we'd have to parse information out of the string. This isn't a good way of doing things. I've introduced a SUCCESS/FAILURE enum for status constants, and added a check for failures in the transport action. We return a 207 if some but not all reset actions fail, and for every failure, we also return information about the exception or error that caused it. * Fix 7.x backport compilation issues * Feature reset integration test should tolerate failed resets (elastic#72326) Co-authored-by: Jay Modi <[email protected]>
williamrandolph
added a commit
that referenced
this pull request
Apr 28, 2021
* Add docs for feature reset API (#71759) * Make feature reset API response more informative (#71240) Previously, the ResetFeatureStateStatus object captured its status in a String, which meant that if we wanted to know if something succeeded or failed, we'd have to parse information out of the string. This isn't a good way of doing things. I've introduced a SUCCESS/FAILURE enum for status constants, and added a check for failures in the transport action. We return a 207 if some but not all reset actions fail, and for every failure, we also return information about the exception or error that caused it. * Fix 7.x backport compilation issues * Feature reset integration test should tolerate failed resets (#72326) Co-authored-by: debadair <[email protected]> Co-authored-by: Jay Modi <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This didn't cause a problem in the branch builds, but it did on the intake build. Basically, in this test we should just be looking for at least one success, but the
containsmatcher required the result to just be "SUCCESS". This was wrong. In fact, it was redundant with a check a few lines above, so it's probably best to just remove it and add a comment about what the test is looking for.